Software 


© G-DYN Multibody Dynamics 
Engine 

G-DYN is a multi-body dynamic simu- 
lation software engine that automatically 
assembles and integrates equations of 
motion for arbitrarily connected multi- 
body dynamic systems. 

The algorithm behind G-DYN is 
based on a primal-dual formulation of 
the dynamics that captures the posi- 
tion and velocity vectors (primal vari- 
ables) of each body and the interac- 
tion forces (dual variables) between 
bodies, which are particularly useful 
for control and estimation analysis and 
synthesis. It also takes full advantage of 
the spare matrix structure resulting 
from the system dynamics to numeri- 
cally integrate the equations of motion 
efficiently. Furthermore, the dynamic 
model for each body can easily be re- 
placed without re-deriving the overall 
equations of motion, and the assembly 
of the equations of motion is done au- 
tomatically. 

G-DYN proved an essential software 
tool in the simulation of spacecraft sys- 
tems used for small celestial body sur- 
face sampling, specifically in simulating 
touch-and-go (TAG) maneuvers of a ro- 
botic sampling system from a comet and 
asteroid. It is used extensively in validat- 
ing mission concepts for small body sam- 
ple return, such as Comet Odyssey and 
Galahad New Frontiers proposals. 

This work was done by Behcet Acikmese, James 
C. Blackmore, and Milan Mandic of Caltech for 
NASA’s Jet Propulsion. Laboratory. For more in- 
formation, contact iaoffice@jplnasa.gov. 

This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-471 95. 


© Multibody Simulation 
Software Testbed for 
Small-Body Exploration 
and Sampling 

G-TAG is a software tool for the multi- 
body simulation of a spacecraft with a ro- 
botic arm and a sampling mechanism, 
which performs a touch-and-go (TAG) 
maneuver for sampling from the surface 
of a small celestial body. G-TAG utilizes 
G-DYN, a multi-body simulation engine 
described in the previous article, and in- 
terfaces to controllers, estimators, and 


environmental forces that affect the 
spacecraft. G-TAG can easily be adapted 
for the analysis of the mission stress cases 
to support the design of a TAG system, 
as well as for comprehensive Monte 
Carlo simulations to analyze and evalu- 
ate a particular TAG system design. 

Any future small-body mission will 
benefit from using G-TAG, which has al- 
ready been extensively used in Comet 
Odyssey and Galahad Asteroid New 
Frontiers proposals. 

This work was done by Behcet Acikmese, 
James C. Blackmore, and Milan Mandic of 
Caltech for NASA’s Jet Propulsion Laboratory. 
Further information is contained in a TSP 
(see page 1 ). 

This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-47196. 


& Propulsive Reaction Control 
System Model 

This software models a propulsive re- 
action control system (RCS) for guid- 
ance, navigation, and control simula- 
tion purposes. The model includes the 
drive electronics, the electromechani- 
cal valve dynamics, the combustion dy- 
namics, and thrust. This innovation fol- 
lows the Mars Science Laboratory entry 
reaction control system design, and has 
been created to meet the Mars Science 
Laboratory (MSL) entry, descent, and 
landing simulation needs. It has been 
built to be plug-and-play on multiple 
MSL testbeds [analysis, Monte Carlo, 
flight software development, hardware- 
in-the-loop, and ATLO (assembly, test 
and launch operations) testbeds] . 

This RCS model is a C language pro- 
gram. It contains two main functions: 
the RCS electronics model function that 
models the RCS FPGA (field-program- 
mable-gate-array) processing and com- 
manding of the RCS valve, and the RCS 
dynamic model function that models the 
valve and combustion dynamics. In addi- 
tion, this software provides support func- 
tions to initialize the model states, set pa- 
rameters, access model telemetry, and 
access calculated thruster forces. 

This work was done by Paul Brugarolas, 
Link H. Phan, Frederick Serricchio, and Ale- 
jandro M. San Martin of Caltech for NASA’s 
Jet Propulsion Laboratory. For more informa- 
tion, contact iaoffice@jpl. nasa.gov. 


This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech.edu. Refer to NPO-46978. 


© Licklider Transmission Pro- 
tocol Implementation 

This software is an implementation of 
the Licklider Transmission Protocol 
(LTP), a communications protocol in- 
tended to support the Bundle Protocol 
in Delay-Tolerant Network (DTN) opera- 
tions. LTP is designed to provide retrans- 
mission-based reliability over links char- 
acterized by extremely long message 
round-trip times and/or frequent inter- 
ruptions in connectivity. Communication 
in interplanetary space is the most 
prominent example of this sort of envi- 
ronment, and LTP is principally aimed at 
supporting “long-haul” reliable transmis- 
sion over deep-space RF links. 

Like any reliable transport service em- 
ploying ARQ (Automatic Repeat re- 
Quests), LTP is “stateful.” In order to as- 
sure the reception of a block of data it 
has sent, LTP must retain for possible re- 
transmission all portions of that block 
which might not have been received yet. 
In order to do so, it must keep track of 
which portions of the block are known to 
have been received so far, and which are 
not, together with any additional infor- 
mation needed for purposes of retrans- 
mitting part, or all, of the block. Long 
round-trip times mean substantial delay 
between the transmission of a block of 
data and the reception of an acknowl- 
edgement from the block’s destination, 
signaling arrival of the block. If LTP post- 
poned transmission of additional blocks 
of data until it received acknowledge- 
ment of the arrival of all prior blocks, 
valuable opportunities to use what little 
deep space transmission bandwidth is 
available would be forever lost. 

For this reason, LTP is based in part on 
a notion of massive state retention. Any 
number of requested transmission con- 
versations (sessions) may be concur- 
rently “in flight” at various displacements 
along the link between two LTP engines, 
and the LTP engines must necessarily re- 
tain transmission status and retransmis- 
sion resources for all of them. Moreover, 
if any of the data of a given block are lost 
en route, it will be necessary to retain the 
state of that transmission during an addi- 
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